Collection of Tools & Utilities/Collection of Tools and Utilities.iso/system/exelink2.zip/EXELINK.DOC

Text File | 1993-06-17 | 12KB | 268 lines

                                  EXELINK.COM
                                  ===========

IMPORTANT NOTE:  Needs DOS 3.0 or greater

#include <std_disclaimer.h>
All the code in this package is my own work.  No responsibility will be
taken for loss of data or damage caused by running this program.  This
program has been tested and I use it myself, so if you do come across
any problems then let me know!

The program can be freely distributed.  There are no restrictions on use.
Just keep my name on it please!
The program is "postcardware" - send me a postcard if you like :-)

Introduction
============
A big problem with Hard discs is that they can store so much data!
This isn't as silly as it sounds; if you have four or five applications
on your disc (maybe Pascal, C, Assembler, Word Processor, Norton etc)
and wish to keep some sort of organisation do your disc then your PATH
variable gets a little large.  Until you reach the dreaded 127
character limit.  Although programs exist that enable you to get up to
255 characters in the PATH, this is a bit long and unwieldy, and can
make you computer spend too much time skipping around directories just
to find the program you want.  I had this problem and decided to find a
better solution, and EXELINK is it (well I think its better!)

What EXELINK does
=================
NOTE: EXELINK will not work with .BAT files since the command shell
interprets them internally and doesn't call the DOS 'exec' routines.
Only routines that call 'exec' (eg .EXE and .COM files, Overlays?)
work.

When you execute a command, MS-DOS needs to find where the file is that
you are trying to run.  It first looks in the current directory, then
in the first directory on the PATH, then the next, then the next...
until it finds what you wanted.

eg if you have your path set up as
c:\dos;c:\app\turbop;c:\app\turboc;c:\app\tasm;c:\app\wp;c:\app\norton
then typing the command 'nu'  (for norton utilities) will involve
looking for
     .\NU.???
     c:\dos\NU.???
     c:\app\turbop\NU.???
     c:\app\turboc\NU.???
     c:\app\tasm\NU.???
     c:\app\wp\NU.???
     c:\app\norton\NU.???
which it will eventually find.  Any files in any of these directories
which are not executable will slow down the searching...
Of course an easy way to speed up access to NU would be to put it at
the front of the PATH, at the expense of some other program!

EXELINK sets aside directory which you include on your PATH (for speed
you put it at the beginning) and this contains a set of files which
appear to DOS to be executable.  Instead of being run though, EXELINK
reads the contents of this file and gets the filename of the REAL
program from there.  Since the link directory is at the beginning of
the PATH and there are only executables it will find the link file very
quickly.
In the example above, you could now have the following setup:
PATH=c:\links;c:\dos
and searching would be
     .\NU.???
     c:\links\NU.???  <- found!  Open the file, read its contents and
                         execute!

Less searching is done, executables are found quicker, PATH is shorter
and less disk head movement is used.

But what is this I hear?  You can do this by creating a BATch files which
calls the real program?  Almost true, but there are a  few problems with
batch files:
 (1) There is difficulty passing an unknown number of parameters.  A batch
     file such as
     @c:\app\wp %1 %2 %3 %4 %5
     can be taken as meaning that is passes exactly five parameters, some
     of which are NULL (GEM programs can suffer from this problem)
 (2) It only works from the DOS prompt - a program such as MAKE is
     unable to use BATch files unless you specifically call COMMAND.COM
     which is slower and takes more memory.
 (3) It is an interpreted file.  DOS opens the BATch file, reads
     a line.  If it executes an external program, closes the BATch
     file, executes the command, opens the BATch file, etc.  Lots of
     disc accessing...

The only real alternative would be to write a specialised Pascal or C
program which just executed the real version with all the parameters
passed on.  This will work in all cases, but has the problem that you
need to compile a new link program for each new executable you want
linked, and even the simplest compiled program takes about 2.5k -
wasting 4k of disc space!
example in Turbo C 2.01:

main(int argc,char *argv[], char **envp)
{
  argv[0]="real_name.exe";
  execve("real_path_name.exe",argv,envp);
}

Which would then need compiling, and even in the TINY memory model
takes over 3k!

Using EXELINK you need to create a 1 line ASCII file which you can do
with the COPY command.
How EXELINK works
=================
EXELINK is a Terminate and Stay Resident (TSR) program.  While resident
it takes an astounding 400 bytes of memory!  The only vector it
attaches to is INT 21h and any call that is not Function 4Bh (exec) is
passed directly onto the original handler.  To cut down on resident size
it frees the environment block passes to it by DOS, and relocates itself
over the PSP, which is no longer needed once the program has gone resident.

If the call is an 'exec' then the pathname of the program to be called
is worked out.  If this program is in the EXELINK directory (by default
C:\LINKS) then the file is opened for reading and the contents of the
file (up to 127 characters) are read in.  A little processing is done
to convert this to an ASCIIZ string and then the original routine
continues with this new name.  All registers are preserved through this
except for DS:DX which point to the filenames so any options passed to
'exec' are preserved.  Also, as far as the called application is concerned,
it was run by typing the full pathname of the program, so that programs that
use the command line (eg WordPerfect) to find the directory it is running
in work properly.


Requirements
============
EXELINK makes use of an internal DOS function:  INT 21h Function 60h -
CANONICALIZE FILENAME OR PATH
This is only available on MS-DOS 3.0 onwards, and I am not sure if this is
a fully documented call.

EXELINK has been tested with:
     PC-DOS 3.20
     vanilla MS-DOS 3.30
     Atari PC2 specific MS-DOS 3.21
     Tri-Gem MS-DOS 3.30
     OEM MS-DOS 5.0
     4DOS v3.01, v3.02, v3.02a, v4.0, v4.01 (a good COMMAND.COM replacement)
     Windows 3.0, 3.1
     DesqView 386 v2.3, v2.4
     Various applications.

Known incompatibilities:
     MKS Tools 3.1c version of the Korn-Shell.
       I have had a lot of problems with the Korn Shell, from TSR's to
       bog-standard applications.  I am unsure as to why this shell fails
       to work with EXELINK since it seems to support INT21/AX=60h
       I have not tested with later versions of MKS tools.

     Turbo C exec() call.
       Turbo C seems to try to open the executable and read the header
       contents to determine the file type.  Of course, these files are
       ASCII and so TurboC returns "Invalid exec type" :-(
       This also affects Borland C++ 3.1 (the Run Time Library Sources
       show why Borland do this - to enable exec() to overlay better)

     Windows 3.0, 3.1.
       I think Windows also tries to open the file to determine
       if a file is a DOS or a Windows executable.  I am not sure.
       However,  EXELINK works happily inside a DOS window.
     DesqView 386.
       It appears that DesqView has its own exec() replacement, and so
       each window that you wish to use EXELINK in must have its own
       copy of EXELINK loaded.  Once this has happened, it works happily
       inside that window.
     Word Perfect for Windows 5.1
       Word Perfect seems to search the PATH to find where your windows
       system resides, so it knows where to put the INI GRP DLL files.
       If WIN.COM is in the links directory then WP4W assumes this is where
       windows lives!  Silly Word Perfect.....before installing this program
       you should modify your PATH so that it has the real windows directory
       at t